home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
e
/
misc.save
/
000058_scottac@nb.sympatico.ca_Fri Jan 19 17:34:22 2007.msg
< prev
next >
Wrap
Internet Message Format
|
2011-07-03
|
6KB
Path: reader2.panix.com!reader1.panix.com!panix!bloom-beacon.mit.edu!news2.wam.umd.edu!elk.ncren.net!newsflash.concordia.ca!News.Dal.Ca!ursa-nb00s0.nbnet.nb.ca!53ab2750!not-for-mail
From: "Scott Caissie" <scottac@nb.sympatico.ca>
Newsgroups: comp.protocols.kermit.misc
References: <xwOhh.34809$cz.516497@ursa-nb00s0.nbnet.nb.ca> <lWShh.32651$tb6.31529@news-wrt-01.rdc-nyc.rr.com> <bF8ih.35271$cz.521966@ursa-nb00s0.nbnet.nb.ca> <4589b00f$0$16922$4c368faf@roadrunner.com> <Gmrih.35742$cz.527501@ursa-nb00s0.nbnet.nb.ca> <458a9baa$0$5926$4c368faf@roadrunner.com> <c3_rh.2668$1x.45361@ursa-nb00s0.nbnet.nb.ca> <45b0c5ad$0$7740$4c368faf@roadrunner.com>
Subject: Re: Macro: Terminal -> Command -> Terminal -> Command?
Lines: 145
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Message-ID: <Nbash.2846$1x.48756@ursa-nb00s0.nbnet.nb.ca>
Date: Fri, 19 Jan 2007 20:51:57 GMT
NNTP-Posting-Host: 156.34.63.9
X-Complaints-To: abuse@aliant.net
X-Trace: ursa-nb00s0.nbnet.nb.ca 1169239917 156.34.63.9 (Fri, 19 Jan 2007 16:51:57 AST)
NNTP-Posting-Date: Fri, 19 Jan 2007 16:51:57 AST
Organization: Aliant Internet
Xref: panix comp.protocols.kermit.misc:15630
I expect these commands to send and process the F6 key to the Terminal. The
Terminal (for me) recognizes this as the Function Key for opening up various
windows.
And the command does in fact work. It sends out the F6 command to be
processed by the Terminal.... but not when its alone. Its works as expected
when its proceeded by a non-\Kverb. So I just throw in non-harmful keys in
front of some of my sequences to guarantee that it will run properly.
That sounds very much like a bug.
"Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message
news:45b0c5ad$0$7740$4c368faf@roadrunner.com...
> What are you expecting
>
> OUTPUT \Kdecf06
> INPUT <n> \Kdecf06
>
> to do?
>
> Since keyboard escape sequences are not going to be echo'd back to the
> terminal for input processing, it is the equivalent of
>
> INPUT <n> "some string that is never ever going to come"
>
> You use the INPUT command to wait for the sequence that the host sends
> in response to the sequence you sent with OUTPUT.
>
>
>
> Scott Caissie wrote:
>> Its a pity that it can't be made faster. 1 second is too long when I have
>> a
>> macro using this numerous times per account.
>>
>> Anyway, I discovered an oddity.
>> Is there a problem with INPUT & Kverbs?
>>
>> On of my macros is trying to use F6 (opens a window for me) but it
>> doesn't
>> function if it is by itself.
>> I have 3 scenarios listed below.
>>
>> Scenario #1 (my original simple setup)
>> OUTPUT \Kdecf06
>> INPUT 1 \Kdecf06
>> The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres
>> no
>> actual pause using 1 rather than 0.
>>
>> Scenario #2
>> OUTPUT \Klfarr\Kdecf06
>> INPUT 1 \Klfarr\Kdecf06
>> This also doesn't work....still no actual pause or updating.
>>
>> Scenario #3
>> OUTPUT \8\Kdecf06
>> INPUT 1 \8\Kdecf06
>> This works. I was wondering if Kverbs had complications with this.
>>
>>
>> I had another macro which uses OUTPUT/INPUT very intensely and
>> occassionally
>> it loses it's place, and I think this might be the reason why. The
>> terminal
>> doesn't seem to always update when it should. Its going to take me about
>> an
>> hour to verify if all my statements are being processed correctly, but
>> before I do that, I want to know precisely what I'm looking for.
>>
>>
>>
>>
>> "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message
>> news:458a9baa$0$5926$4c368faf@roadrunner.com...
>>> The value is a "timeout" period not a time-you-must-wait-for period.
>>> You could put 1000 there and it wouldn't make a different provided that
>>> the data you are looking for actually arrives. The value is "how long
>>> should I wait if the pattern I was given does not find a match on the
>>> incoming data stream?"
>>>
>>>
>>>
>>> Scott Caissie wrote:
>>>> That is what my tests today showed.
>>>> With this, I'll have macros that will be running in a loop for about
>>>> 50-200
>>>> times.
>>>> For each, I need only one "INPUT 1" statement at the end to update the
>>>> screen. Up until that point, using a multitude of INPUT 0s works fine.
>>>> 1
>>>> of
>>>> my projects will need to update the screen twice.
>>>> I ran one today a few times in a loop of 119 times. Worked perfectly.
>>>>
>>>> Though I wish you could allow for fractions of a second. Or an
>>>> instaneous
>>>> forced update command.
>>>> That would be my wish list for Version 3.0.
>>>>
>>>> But this so far has helped me a lot. Thanks.
>>>>
>>>> - Scott
>>>>
>>>> "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message
>>>> news:4589b00f$0$16922$4c368faf@roadrunner.com...
>>>>> Scott Caissie wrote:
>>>>>> I see. I've been testing this out all day, and it works pretty much
>>>>>> the
>>>>>> way
>>>>>> I was aiming for. I was never referred to using the INPUT command
>>>>>> before,
>>>>>> and to be honest, I don't understand it 100% yet. I'm basically
>>>>>> mirroring
>>>>>> my
>>>>>> actions.
>>>>>> I do have a question. Is there restrictions about using INPUT 0
>>>>>> <text>?
>>>>>> This example works fine, but if I use INPUT 0 etc, it won't. I check
>>>>>> to
>>>>>> see
>>>>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
>>>>>>
>>>>>> SET INPUT TERMINAL ON
>>>>>> set input echo off
>>>>>> clear input-buffer
>>>>>> define vega {
>>>>>> ..LZ_PRO := \Fscrnstr(0,6,8)
>>>>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
>>>>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
>>>>>> for \%t 1 24 1 {
>>>>>> echo \Fscrnstr(\%t,0,79)
>>>>>> }
>>>>>> }
>>>>> If you use "INPUT 0 <text>" you are not reading any data from the
>>>>> connection. You must use a timeout greater than 0 in order to process
>>>>> data.
>>>>>
>>>>> Jeffrey Altman
>>>>
>>
>>